k3s follow-up: channels via INSTALL_K3S_CHANNEL, *.yml data-dir (after #8) - #9

Review: c4adaf8 against 1d61656 (and bootstrap-device 6ec99e5)

Verdict: changes requested (one must-fix).

Must fix: an upgrade to a vMAJ.MIN channel skips the downgrade and multi-minor checks

With TN_K3S_UPGRADE=true and INSTALL_K3S_VERSION=v1.33 (or the new tnctl bootstrap --k3s-version v1.33 --k3s-upgrade), tn_inst_normalize_pin turns the value into INSTALL_K3S_CHANNEL=v1.33. tn_inst_plan then finds no exact target (tn_inst_cmp fails), prints only the "not an exact release" warning and hands the channel to the installer.

I ran this under dash with a fake installer and k3s v1.34.11+k3s1 installed:

At 1d61656 these requests failed safe by accident. Now they go through, and the bootstrap-device re-vendor (6ec99e5) inherits the same path, because TN_K3S_VERSION=v1.33 is exported as INSTALL_K3S_VERSION.

The channel name gives the minor version exactly; tn_inst_cgroup already reads it that way. In the upgrade branch of tn_inst_plan, when INSTALL_K3S_CHANNEL is vMAJ.MIN:

• refuse a lower minor or a different major (downgrade);
• refuse more than one minor above the installed one, unless TN_K3S_FORCE=true.

A same-minor channel is fine, because channels only move forward.

Recommended, not blocking: also resolve stable/latest/testing before the checks, the way install.sh does (curl -w '%{url_effective}' -L ${INSTALL_K3S_CHANNEL_URL:-https://update.k3s.io/v1-release/channels}/$ch, then take the basename). That gives channels the full checks. If it cannot be resolved, keep today's warning. Strictly, INSTALL_K3S_VERSION=stable with an upgrade also used to fail safe (404). But INSTALL_K3S_CHANNEL=stable and --k3s-version stable already behaved like today at 1d61656, so I am not counting it as a regression.

Verified OK

• Channels go to INSTALL_K3S_CHANNEL (dash, fake installer, no k3s installed): stable, latest, testing and v1.34 given as INSTALL_K3S_VERSION reach the installer as INSTALL_K3S_CHANNEL=<value>, with INSTALL_K3S_VERSION unset.

• Exact versions are unchanged: v1.36.5+k3s1 and v1.36.5-rc1+k3s1 pass through as they did at 1d61656. A plain INSTALL_K3S_CHANNEL=latest is also unchanged.

• Keep-installed (no TN_K3S_UPGRADE): an exact pin, a channel or the same release keeps the installed v1.34.11+k3s1, as at 1d61656.

• Exact-pin upgrades: a downgrade (v1.33.1) is refused, a jump to v1.36.5 is refused, v1.35.2 is allowed, and FORCE allows v1.36.5. All match 1d61656.

• cgroup v1, upgrade from v1.30.5:

  • channel v1.31: no INSTALL_K3S_EXEC flag, which is correct because v1.31 does not need it on its first start;
  • channel v1.36: --kubelet-arg=fail-cgroupv1=false is added.

• Agent (local fake server publishing v1.34.11+k3s1):

  • a channel or vMAJ.MIN flag pin installs the server's exact release;
  • an exact pin newer than the server is refused, and an older one is installed;
  • with the server unreachable, a channel pin is refused and an exact pin is installed with a warning;
  • an agent upgrade follows the server.

  All identical to 1d61656.

• Data-dir drop-ins: tn_ca_config_dropins matches k3s v1.36.5 pkg/configfilearg.dotDFiles, which uses os.ReadDir, so the list is in byte order, matched with HasSuffixI(".yaml", ".yml"). Under dash, 10-b.yml, 15-e.Yml, 20-c.YAML, Z-f.yaml and a-g.yaml came out in k3s order, last one wins (/g). 30-d.txt and a directory named sub.yaml are skipped.

• go test ./... passes. The three vendored files in bootstrap-device 6ec99e5 are identical to c4adaf8.

Notes (not blocking, already true at 1d61656)

• Symlinked drop-ins: k3s reads a drop-in that is a symlink (IsDir() is false for a symlink), but find -type f skips it. -type f → \( -type f -o -type l \) (or -xtype f) would match k3s.
• Pin source in bootstrap-device: 00_tn_header.sh sets TN_K3S_PIN_SOURCE from INSTALL_K3S_VERSION only. The cli template also counts INSTALL_K3S_CHANNEL. The header comment there still says config.yaml.d/*.yaml.
• Conflicting values: when INSTALL_K3S_VERSION is a channel and INSTALL_K3S_CHANNEL is also set, the version wins and overwrites the channel. That is reasonable, but it is worth a line in the docs.

🤖 Generated with Claude Code

Delta review: c4adaf8..8ba02da (cli) and 6ec99e5..46cbdcd (bootstrap-device)

Verdict: approve. No must-fix. This delta adds no path that proceeds where 1d61656 refused. It also never installs a release other than the one 1d61656 (or the k3s installer) would have picked. Every behaviour change is a new refusal, and a refusal happens in tn_inst_prepare, which runs before tn_k3s_ca_setup in both server templates. A refused run therefore leaves the device untouched.

How it was checked

I used a separate harness under dash with set -e and noglob. It runs a fake k3s --version, a stub curl (a redirect from update.k3s.io, or exit 6 when the channel cannot be resolved, plus /static/teknoir/k3s-version for agents) and tn_inst_prepare. Each case ran against the libraries at 1d61656, c4adaf8 and 8ba02da.

Channel cases with v1.34.11+k3s1 installed (the channel given as INSTALL_K3S_VERSION or as INSTALL_K3S_CHANNEL; results were identical either way):

The %2B in the redirect decodes to +. Once pinned, INSTALL_K3S_CHANNEL is unset, so the installer is given only INSTALL_K3S_VERSION.

cgroup v1 with v1.30.14 installed:

• stable → v1.31.9: deferred, EXEC unchanged.
• stable → v1.36.5 with force: EFFECTIVE=v1.36.5 and --kubelet-arg=fail-cgroupv1=false added to EXEC. Resolving the channel makes this more precise than before.
• stable that cannot be resolved, with force: the flag goes into EXEC, as at 1d61656.
• channel v1.31: deferred, no flag.

Exact versions, unchanged against 1d61656: 336 server cases with 0 differences in rc, action, version, channel, effective, EXEC or deferred. The matrix crossed:

• installed: none, 1.30.14, 1.33.2, 1.34.11, 1.35.9, 1.36.5+k3s1 and +k3s2
• pins: 1.33.2, 1.34.11 (with and without +k3s1), 1.35.9, 1.36.5, 1.36.6
• with and without TN_K3S_UPGRADE, with and without TN_K3S_FORCE
• cgroup v1 and v2

Agent path, unchanged against 1d61656: 288 cases with 0 differences. The matrix crossed:

• installed: none, 1.34.11, 1.35.9
• server: unreachable, 1.34.11, 1.35.9, 1.36.5
• pin: none, 1.36.5, 1.34.11
• TN_K3S_PIN_SOURCE: default or flag
• with and without TN_K3S_UPGRADE, with and without TN_K3S_FORCE

The one new agent behaviour: TN_K3S_UPGRADE + TN_K3S_FORCE + an unreachable server + a channel now pins the release that stable resolves to, where it used to pass the channel on. Both install the same release.

Other checks:

• go test ./... passes.
• bootstrap-device check-vendored.sh --cli: all 3 libraries and the 16 harness files are identical to 8ba02da.
• Both branch heads match origin.

Notes (non-blocking; follow-ups worth considering)

1. The conflict refusal also fires on a plain re-run and on a fresh install, not only on an upgrade. A script made with tnctl bootstrap --k3s-version stable bakes in INSTALL_K3S_CHANNEL=stable. Running it as INSTALL_K3S_VERSION=v1.35 sh bootstrap.sh is now refused ("set only one of them"), even with no upgrade. At 1d61656 and c4adaf8, that re-run kept k3s and finished the repair. The person set only one of the two; the template set the other. Two options: let the env INSTALL_K3S_VERSION win over the template's channel, or refuse only when the channel is actually used (fresh install or upgrade). The device is not damaged (the refusal comes before the CA step), but the repair is blocked.
2. A non-exact pin with TN_K3S_UPGRADE has no override any more. For example, v1.35.0-rc1+k3s1 is now refused even with TN_K3S_FORCE=true. 1d61656 warned and went on. Consider allowing it, unchecked, with force, the same way an unresolvable channel is allowed.
3. The resolve curl has no timeout and no wget fallback.
   • Add --connect-timeout/--max-time, as tn_inst_http_get does (10 s). On a network that silently drops packets, curl can otherwise hang for minutes.
   • Without curl (wget-only hosts, which install.sh supports), the channel is refused unless TN_K3S_FORCE=true.
4. INSTALL_K3S_CHANNEL_URL is ignored. install.sh resolves ${INSTALL_K3S_CHANNEL_URL:-https://update.k3s.io/v1-release/channels}/$channel. With a mirror, the library resolves against a different server than the installer would use, and refuses when update.k3s.io cannot be reached.
5. A minor channel is only compared by major.minor. If an exact pin left the device ahead of the channel head (for example v1.34.12 installed while channel v1.34 still points to v1.34.11), the channel can resolve to a lower patch and the upgrade is allowed. update.k3s.io resolves v1.34 the same way it resolves stable. Resolve it first and fall back to the minor comparison only when it cannot be resolved.
6. bootstrap-device: I agree with leaving TN_K3S_PIN_SOURCE as it is. Its templates never set INSTALL_K3S_CHANNEL, and the header comment matches what the vendored library does.

Nothing was merged. fix/k3s-ca-root-keycertsign and the VM rig were not touched.

🤖 Generated with Claude Code